An Ethernet Virtual Connection (EVC) refers to a logical relationship between Ethernet user-to-network interfaces (UNI) in a provider-based Ethernet Service. A Metro Ethernet is a computer network that covers a metropolitan area and that is based on the Ethernet standard. Furthermore, a Metro Ethernet is commonly used as a metropolitan access network to connect subscribers and businesses to a larger service network, the Internet, and/or other network system.
In a Metro Ethernet Network, the provider (e.g., an operator) often has the need to validate the EVC service provided to a customer. This validation typically consists of verifying a Service Level Agreements (SLA) associated with the EVC service. Performing this validation is critical when a new service is provisioned in the Metro Ethernet Network and when a live service needs troubleshooting. Validating for a new service generally requires an out-of-service test and troubleshooting a live service generally requires an in-service test. In one example, a main objective of a Metro Ethernet Network operator is to perform a network test according to RFC (Request For Comments) 2544.
According to the Metro Ethernet Forum (MEF) recommendations, SLA validation comprises measurements relating to packet loss, packet delay and packet delay variance. To this end, in order to provide an accurate SLA validation, it is critical to validate the network between the end points of the Ethernet Service (e.g., User Network Interface (UNI) ports), so that the Quality of Service (QOS) requirements set for the Ethernet Services are honored (i.e., EVC Ethernet Service UNI-to-UNI SLA verification). To this end, as shown within the network system 100 in FIG. 1A, traffic generator functionality 102 causes test frames to be injected at a UNI port 104A of a local network element 104, which are also connected to a customer networks 106. The local network element 104 is connected to a remote network element 110 through a carrier network 112. The carrier network 112 is connected to each one of the network elements 104, 110 through their respective network-to-network interface ports 104B, 110B. Traffic analyzer functionality 114 causes the test frames received at a UNI port 110A of the remote network element 110 to be analyzed.
Various solutions exist to deploy traffic generators and analyzers within the Metro Ethernet Network to test a customer Ethernet Service and verify the Service Level Agreement (SLA) associated to the service. These external traffic generators and analyzers must be connected to the UNI ports in order to test the Ethernet Service and implies that only out-of-service tests can be performed. A skilled person will appreciate that management of this traffic generator and analyzer equipments and the tests that need to be performed is not trivial and often requires proprietary software applications. For example, the operator has to individually configure separate test devices and traffic generators using disparate configuration options and, in general, management agents (i.e., agents of a network management system (NMS)) don't get a unified picture of the configuration and test results.
One known (i.e., prior art) solution for carrying out EVC validation relies upon the use of one or more network interface devices (NIDs). FIG. 1B depicts such a NID based solution in the context of the network system discussed above in reference to FIG. 1A. A local NID 116 and a remote MD 118 serve as a demarcation point between the carrier network 112 and the customer network 106. The NIDs 116, 118 can each offer an integrated traffic generator and traffic analyzer allowing in-band network performance measurement between both end points of the Ethernet Service (i.e., UNI port 104A and UNI port 110A). This solution exhibits relatively high capital expenditure for the service provider because two NIDs 116, 118 must be deployed for each customer point-to-point Ethernet Service. Accordingly, with large service provider networks, the solution can become too expensive.
Another known solution for carrying out EVC validation relies upon the use of a centralized test head. FIG. 1C depicts such a centralized test head based solution in the context of the network system discussed above in reference to FIG. 1A. A test can be started from a centralized test head 120. Typically, the test head 120 is connected in a network element within the carrier network 112 and test frames are injected from the carrier network 112 into a port of the network element 104. In combination with loop-back functionality on the network element, test frames are looped back by the remote network element 110 (i.e., the targeted network element) for delivery to the centralized test head 120 for performance measurements. This solution has the drawback of not validating the network path between the customer endpoints.
In view of the shortcomings associated with know solutions for carrying out EVC validation, a network element serving as an access switch or provider edge for providing a test generator/analyzer functionality that allows an service provider (e.g., operator) to validate the Metro Ethernet network between the end points of the customer Ethernet Service would be useful, advantageous and novel.